REMARKS 

This application has been reviewed in light of the Office Action dated 
November 26, 2008. Claims 2-4, 6-18, 39 and 40 are presented for examination, of which 
Claim 39 is in independent form. Claim 5 has been canceled and its features have been 
incorporated into Claim 39. Claim 40 has been added and incorporates features that were 
previously in Claim 39. Claims 2, 7, 9 and 39 have been amended to define Applicants' 
invention more clearly. Favorable reconsideration is respectfully requested. 

The Office Action states that Claims 2-18 and 39 are rejected under 
§ 103(a) as being unpatentable over U.S. Patent No. 6,070,142 {McDonough et al) in view 
of U.S. Patent No. 6,014,645 {Cunningham) and further in view of U.S. Patent Apphcation 
Publication No. 2001/0044840 (Carleton). 

The aspect of the present invention set forth in Claim 39 is directed to an 
acquisition system, which could be applied to the financial services industry, for example. 
See Specification, para. [0003]. The acquisition system includes 1) a client interface for 
accepting client requests. See Fig. 2, 20. For example, a client request could be a request 
fi-om a brokerage firm to open a brokerage account for a customer. The acquisition system 
also includes 2) a dispatcher for routing client requests. See Fig. 2, 1 10 and Specification, 
para. [0015]. 

In addition, the acquisition system includes 3) a plurality of client- or 
function-specific handlers for implementing appropriate business logic. See Fig. 2, 112. 
For example, a handler could be a system that manages the tasks for opening a brokerage 
account with the brokerage firm, including data capture, account setup and activation, and 
customer notification. The dispatcher routes each client request to an appropriate handler. 
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Furthermore, the acquisition system includes 4) a pluraUty of workers for accomplishing 
common tasks. See Fig. 2, 1 14. For example, a worker could be a system for data capture, 
saving a log entry consisting of a client ID, a request type, and a timestamp into a 
particular memory location. Each handler invokes one or more workers according to 
appropriate business logic, and multiple handlers could invoke the same worker to 
accomplish the same sort of tasks. 

In this way, there is a clean separation between business logic and common 
tasks, which enables effective reuse of workers and easy addition (for a new client, for 
example) or change of business logic (para. [0016]). In general, a client may rely on 
existing workers. However, for increased efficiency, for example, a client may introduce 
new workers to increase the amount of resource available for accomplishing common 
tasks. 

Yet another notable feature of Claim 39 is that a new worker utility is 
configured by either a corresponding client or one of the handler systems to be re-used by 
any of the cUents. See, e.g., Specification, para. [0016-0019]. 

Nothing has been found in McDonough, Cunningham, or Carleton, 
considered separately or in any permissible combination, that is believed to teach or 
suggest all the features of Claim 39. A detailed explanation supporting this assertion 
follows. 

A Plurality of Handlers and A Plurality of Workers 

Claim 39, as amended, recites "a dispatcher configured to route each of the 
plurality of event requests to at least one of a plurality of handler systems, each handler 
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system configured to invoke at least one of a plurality of worker utilities according to 
business logic for handling a respective event request, each worker utility configured to 
perform one or more tasks to fiilfill the respective event request, . . . wherein. . . all of the 
plurality of handler systems are enabled to invoke any of the worker utilities" 

The Office Action states that McDonough discloses these features. 
Applicants respectfully disagree. 

McDonough relates to a virtual customer and sales service center. As 
understood by Applicants, when a customer submits a request by phone, where the request 
is accepted by a voice response unit (VRU) {see Fig. 4, 440), via the internet {see Fig. 4, 
430), etc., the request is sent to a context manager {see Fig. 4, 402), which passes the 
request to a service provider {see Fig. 4, 410), which analyzes the request and determines 
how to route the request to an appropriate resource to best handle the request. 

The Office Action suggests that a VRU 'm McDonough corresponds to a 
handler of Claim 39 (top of page 4 of the Office Action). The Office Action further 
suggests that either the context manager invoking the functionality of address change or a 
service provider implementing this functionality in McDonough corresponds to a worker of 
Claim 39 (bottom of page 4 of the Office Action; see Fig. 7 and col. 10, line 61 through 
col. 11, line 9 o^ McDonough). 

Applicants submit that a VRU does not correspond to a handler of Claim 39 
at least because it does not perform business logic specific to a client or function and 
"invoke at least one of a plurality of worker utilities according to the business logic," as 
recited in Claim 39. In addition. Applicants submit that even assuming that the context 
manager corresponded to a worker of Claim 39, there does not exist "a plurality of worker 
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utilities," as recited in Claim 39. Similarly, Applicants submit that a service provider does 
not correspond to a worker of Claim 39 at least because it cannot be invoked by "all of the 
plurality of handler systems," as recited in Claim 39. 

Accordingly, McDonough is not believed to disclose or suggest a plurality 
of handlers and a plurality of workers of Claim 39. Even if Cunningham and Carleton are 
deemed to show all that they are cited for, such would not remedy the deficiency discussed 
above. 

A Client Adding A Worker 

Claim 39 also recites that "at least one of the plurality of clients is enabled 
to add a new worker utility." 

While conceding that this feature is not disclosed or suggested in 
McDonough^ the Office Action states that it is in Cunningham. Applicants respectfully 
disagree. 

Cunningham relates to a financial card application system (FCAS) . The 
Office Action states that a card server in Cunningham corresponds to a "worker" without 
specifying what would correspond to a "client," as recited in Claim 39, which submits one 
or more event requests. As understood by Applicants, Cunningham does not discuss who 
and what would supply a card server to the FCAS but only when a card server would be 
added - depending on the total amount of transaction in the system {see col. 3, lines 46-52 
of Cunningham, for example). It could very well be an administrator or manager of the 
FCAS who introduces a new card server, where such a person does not submit any event 
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request to the FCAS and thus would not correspond to the cUent of Claim 39. However, 
this is far from a client adding a new worker. 

Moreover, Applicants have found nothing in Cunningham, that would 
teach, suggest or otherwise result in "wherein the new worker utility is configured by at 
least one of a corresponding client and one of the handler systems to be re-used by any one 
of the plurality of clients," recited in Claim 39. 

Accordingly, Cunningham is not believed to disclose or suggest a client 
adding a worker recited in Claim 39. Even if Carleton is deemed to show all that it is cited 
for, such would not remedy the deficiency discussed above. 

Accordingly, Applicants submit that Claim 39 is patentable over the cited 
art, and respectfully request withdrawal of the rejection under 35 U.S.C. § 103(a). 

A review of the other art of record has failed to reveal anything that, in 
Applicants' opinion, would remedy the deficiencies of the art discussed above, as applied 
against amended claim 39. Therefore, Claim 39 is respectfully submitted to be patentable 
over the art of record. 

The other rejected claims in this application depend from Claim 39 and, 
therefore, are submitted to be patentable for at least the same reasons. Since each 
dependent claim is also deemed to define an additional aspect of the invention, individual 
reconsideration of the patentability of each claim on its own merits is respectfully 
requested. 

In view of the foregoing amendments and remarks, Applicants respectfully 
request favorable reconsideration and early passage to issue of the present application. 
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No petition to extend the time for response to the Office Action is deemed 
necessary for this Amendment. If, however, such a petition is required to make this 
Amendment timely filed, then this paper should be considered such a petition and the 
Commissioner is authorized to charge the requisite petition fee to Deposit Account 50- 
3939. 

Applicants' undersigned attorney may be reached in our New York office 
by telephone at (212) 218-2100. All correspondence should continue to be directed to our 
below listed address. 

Respectfully submitted, 

/Jonathan Berschadsky/ 
Jonathan Berschadsky 
Attorney for Applicants 
Registration No. 46,551 

FITZPATRICK, CELLA, HARPER & SCINTO 
30 Rockefeller Plaza 
New York, New York 101 12-3801 
Facsimile: (212)218-2100 
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